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HANDLING PARAMETERS IN BLOCK DIAGRAM MODELING 

BACKGROUND 

The invention relates to handling parameters in block diagram modeling. 

Dynamic systems may be modeled, simulated and analyzed on a computer system 
5 using graphical block diagram modeling tools, e.g., Simulink® from The Math Works Inc. 
Graphical block diagram modeling graphically depicts mathematical relationships among a 
system's inputs, states, parameters, and outputs, typically through the use of graphical user 
interface. 

In a graphical context, a block diagram is a directed graph containing nodes and arcs 

10 providing a means by which the nodes can conmiunicate. In most block diagramming 

paradigms, the nodes are referred to as blocks and drawn using some for of geometric object 
(e.g., circle, rectangle, etc.) and the arcs are typically drawn using line segments connecting 
the geometric objects. These line segments are often referred to as signals. For example, 
some Simulink® block diagrams enable the user to model dynamic systems where each 

15 block represents a functional entity that mathematical operations and transformations on the 
data (variables) being processed by a system and therefore implements a set of equations. 
The signals represent a time-varying quantity that is updated, i.e., read-by and written-to, by 
the blocks. Within SimuUnk®, blocks execute using a predetermined ordering and with 
control-flow semantics. Other types of graphical block diagrams include data-flow block 

20 diagrams wherein blocks wait for data to be valid before they execute. 

Within Simulink®, executing a graphical block diagram model refers to solving the 
equations defined by the nodes in the directed graph. The order of execution of the nodes is 
dictated by the direction of the arcs that connect the nodes. Graphs with strongly connected 
components (i.e., nodes that form cycles) can be executed by solving each cycle 

25 simultaneously as a coupled set of equations. 

In theory, there can be a nxnnber of equations (often referred to as block methods) that 
are associated v^th a block. For example, Simulink® supports various types of block 
methods. One such block method is an output method, expressed in the form of 

30 y = OutputMethod (t^ X, u, p) 
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where y is typically a set of block output signals (or some other forms of output, e.g., a 
logging device such as a plotting tool or a data archiving block), t is time, x represents a set 
of continuous states and discrete states, u represents the set of input signals to the block and 
p represents a set of parameters supplied to the block. 

A user can parameterize a block with user-defined values by specifying the 
parameters p that are to be used by the block. For example, Simulink® allows a user to 
specify block parameters through a dialog box or programmatically via a 'set j)aram' 
command. 

As indicated earlier, a parameter can take on a wide variety of attributes. In addition, 
a parameter can be defined as an expression. For example, for a gain block that has an output 
method y=p*u^ where p represents a single parameter, a user could define the parameter p 
as a numeric quantity (e.g., 1 : 10), an expression of variables and functions, e.g., 
a*b+sin ( c), or a combination of the two. 

Using the equations defined by the blocks, block diagrams can be executed in an 
interpreted environment that produces a simulation result as defined by the blocks and 
signals in the model. In addition, code can be generated from the block diagrams and 
executed in an executive. The executive is often referred to as an execution framework for 
the generated code. It is responsible for executing the generated code by calling the entry 
points in the generated code at the right times. 

SUMMARY 

In one aspect, the invention provides methods and apparatus, including computer 
program products, for manipulating graphical block diagram block parameters in a graphical 
block diagram modehng environment. The methods include receiving a graphical block 
diagram of blocks for a model developed by a user and processing parameters specified for 
each of the blocks by the user to produce run-time parameters. 

Particular implementations of the invention may provide one or more of the following 
advantages. 

The parameter processing mechanism provides the ability to create optimized 
equations that use specific run-time parameter configurations derived from the dialog 
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parameters entered by the user. For example, the parameter pooUng makes optimal use of 
the constant data memory allocated to block parameters. Run-time parameter pooling 
achieves optimal data store (parameter data reuse) in both a simulation environment and in 
automatically generated code. 

5 In addition to the pooling of constant parameters, a block can specify that a parameter 

it is using in its equation is constant, even if that parameter is specified by a user as an 
interfaced variable. Within block diagrams, user's can explicitly designate certain variables 
as interfaced and, therefore, in this context, an interfaced variable is a variable name that has 
been specified as a parameter or part of a parameter expression. Interfaced variables can be 

10 accessed and updated during block diagram simulation or in the resulting generated code for 
the block diagram while the generated code is executing. Marking a parameter as constant 
means that the interfaced variable Will not be accessible and that the parameter values will be 
pooled, thereby enabling further parameter pooling. Under this scenario, the parameter 
processing mechanism can issue a warning informing the user of the situation. 

1 5 The parameter processing mechanism also enables preservation of interfaced 

variables contained within parameter expressions in generated code. The ability to maintain 
the structure of parameter expressions in the generated code allows users of a block diagram 
tool to solve a larger class of problems. By maintaining the structure of expressions in this 
manner, more flexibility is afforded when a user's executive is running (calling) the 

20 generated code. The executive (execution framework) can probe and update the values of the 
interfaced variables. 

The definition of run-time parameters and mapping of user-specified parameters to 
run-time parameters enables a graphical block diagram tool to produce optimal 
implementations of the block equations for a given user supplied data set. Users can also 
25 create their own blocks with block equations optimized for run-time parameters, thus 
enabling the user of a graphical block diagram tool to extend the parameter processing 
optimizations and mappings in simulation execution or automatically generated code to 
custom blocks. 

Other features and advantages of the invention will be apparent from the following 
30 detailed description and from the claims. 



3 
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DESCRIPTION OF DRAWINGS 

FIG. 1 is a block diagram of a system that includes a file server that stores a graphical 
block diagram modeling/simulation module that includes a model editor and simulator that 
supports block diagram parameter processing and client systems that access a file server and 
execute processes of the graphical block diagram modeling/simulation module for graphical 
block diagram model development and execution. 

FIGS. 2A-B are depictions of an exemplary library of graphical blocks libraries 
provided by the graphical block diagram modeling/simulation module (of FIG. 1) and 
available for use in developing and executing a graphical block diagram model. 

FIG. 3 is an exemplary screen display from a GUI of a client system executing the 
model editor of the graphical block diagram modeling/simulation module (of FIG. 1) dtiring 
graphical block diagram model development. 

FIG. 4 is an exemplary block parameter dialog box in which a user specifies 
parameters expressions. 

FIG. 5 is a flow diagram of the operational flow of the module shown in FIG. 1 . 

FIG. 6 is a flow diagram of the operational flow of a block diagram processing engine 
that processes block diagram block parameters specified by a user. 

FIG. 7 is a flow diagram of the operational flow of a compiler of the block diagram 
processing engine (shown in FIG. 6). 

FIG. 8 is an exemplary block data structure illustrating parameter-related aspects of 
the block. 

FIG. 9 is a flow diagram of the dialog parameter evaluation/processing step (from 
FIG. 7). 

FIGS. lOA and lOB are exemplary depictions of an Abstract Syntax Tree generated 
by the dialog parameter evaluation (shown in FIG. 9). 

FIG. 1 1 is a flow diagram of the run-time parameters setup process (fi:om FIG. 7) 
FIG. 12 is a flow diagram of the parameter pooling process (from FIG. 7). 
FIG. 13 is a flow diagram of the execution structure setup process (from FIG. 7). 
Like reference numerals wall be used to represent like elements. 
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DETAILED DESCRIPTION 

Referring to FIG. 1, a system 10 includes client systems 12a, 12b,...-, 12k and a file 
server 14 each connected to a network 16, e.g., an Ethernet network, the Internet, or other 
type of network. Alternatively, instead of being connected to a network, the systems 12 and 
14 could be interconnected by a system bus such as Fibre Channel. Each of the cHent 
systems 12a, 12b, 12k includes a graphical user interface (GUI) 18a, 18b, 18k. The 
file server 14 is configured with a graphical block diagram modehng and simulation module 
20 (hereinafter, simply, "the module"), which is implemented in software. The module 20 
includes a model constructor/editor 22, as will be described later. The module further 
includes a blocks library 24 and a block diagram processing engine 26. As will be explained 
more fully below, the model editor 22, in conjunction v^th the library 24, is used by a client 
system user to construct and display a graphical block diagram model which visually and 
pictorially represents a dynamic system of interest to that user. The block diagram 
processing engine 26 processes the block diagram model to produce simulation results or, 
optionally, to convert the block diagram model to executable code. 

The system 10 illustrates a remote client access configuration in which the module 20 
is installed on a central file server, i.e., the file server 14, and users of the client systems 12 
access the module 20 over the network 12. In an alternative configuration, e.g., in an 
environment in which access to the library 24 is not shared by multiple users, the module 20 
could be installed on a single stand-alone or networked computer system for local user 
access. 

Each of the client systems 12a, 12b,..., 12k, includes a respective memory 30a, 
30b,. . 30k, for storing all or accessed portions of the module 20, as well as a respective 
CPU 28a, 28b, . . ., 28k for executing the stored portions of the module 20, the GUI 1 8 and 
other OS programs (not shown) for controlling system hardware. Although not shown, it will 
be understood that the systems 12 and 14 can be, in other respects, of a conventional design 
and architecture. That is, the systems 12 include conventional system I/O peripherals, e.g., 
display, mouse, keyboard and the like, for enabling user interaction with the system. The file 
server 14 includes conventional server software and hardware and thus includes the 
appropriate storage for storing the software programs of the module 20, along v^th OS and 
server application programs, and CPU for executing those programs. 
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For illustrative purposes, the module 20 will be described within the context of a 
Simulink® and MATLAB® based simulation environment. Simulink® and MATLAB® are 
commercial software products available from The MathWorks, Inc. The Simulink® software 
package includes a number of different tools, such as special user interfaces and navigational 
tools, e.g., a library browser, which will be referenced in the description to follow. Further 
details of these tools and interfaces can be had vsdth reference to available Simulink® and 
MATLAB® product documentation. It will be understood, however, that any other block 
diagram based modeling software platforms could be used such as the data-flow block 
diagram paradigm. 

The module 20 enables users to copy graphical blocks into their models from the 
libraries 24 (or, optionally, from external libraries). Alternatively, or in addition, the module 
20 allows a user to implement a custom (user-defined) block for use in a model and to add 
that custom block to the library 24 if the user so chooses. In a Simulink® product context, 
the custom, i.e., user written, blocks are known as "S-fiinction blocks". 

FIGS. 2A-2B provide screen shot depictions of an exemplary embodiment of the 
library 24 as a Simulink® library as presented in a window of a Simulink® library browser 
40. As shown in FIG. 2A, the library 24 is a collection of libraries 42 each corresponding to 
different groupings or categories of blocks. It will be appreciated that the libraries are 
represented within the context of the library browser's tree structure as nodes or icons. As 
shown in FIG. 2B, each library 42 includes a set of one or more blocks 44. In the particular 
example shovm in FIG. 2B, a user has selected a "sources" library, which includes among the 
members of its set of graphical source blocks the graphical blocks "pulse generator", "ramp", 
"random number", "repeating sequence", "signal generator", "sine wave", "step" and 
"uniform random nximber". These blocks all represent signal generator fimctionality and are 
therefore grouped together in the sources library. Thus, a user operating one of the client 
systems 12 uses the blocks 44, for example, the sine wave block, to build a graphical block 
diagram using the model editor 22. 

A user selects blocks using a menu provided by the library browser 40. Having 
opened a model window for a model to be generated and/or edited, the user copies the 
selected blocks from the library window to the model window, e.g., by selecting ("clicking 
on") a corresponding library node or icon, dragging the block from the library browser and 
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dropping it in the model window. 

FIG. 3 illustrates a Simulink ® model window 50 that displays an exemplary block 
diagram model 52 created by a user using the model editor 22. The block diagram model 52 
includes a sine wave block 54 that drives a first gain ("gainl") block 56 and a lookup table 
block 58. The gainl block 56 feeds a second gain C'gain2") block 60. The gain2 and lookup 
table blocks 60, 58, respectively, in turn provide inputs to a sum block 62, the output of 
which is provided as an input to an S-function block (S-Fimctionl") 64. The output of the S- 
function block 64 is provided to an outport block (Outl) 66. 

Each of the blocks in the model 50 implements a specific operation (i.e., an algorithm 
or equation). In general, the equations defined by the blocks include user specified 
parameters. As indicated above, the user-specified parameters are expressions that may be in 
the form of numerical values, variables defined as constants, interfaced variables or some 
combination thereof. An interfaced variable is a variable whose value can be changed either 
during simulation or in generated code, as will be discussed in further detail later. 

For example, the output method for the S-fimction block 64, in the form y=u*p, 
where output y is 'sfunl_out', input u is the output of the sirni block 62 'sum_out' and 
parameter p is a parameter expression 'prmll + (prm2-prm3)', is 'sfiml out ^ prml + 
(prm2 -prmS ) * sum^out ' . The variables prml, prm2 and prm3 each are user-specified 
parameters. A pseudo code example for the entire block diagram model 52 is as follows: 

ExecutionLoop : 

sine_out = sin{t); 

gainl_out ^ sine_out .* gainl_parameter ; 
gain2_out= gainl_out gain2__parameter ; 
look-up_out = sine_out .* look-up_paraineter; 
suin_out = gain2_out + look-up_out; 
sfunl^out = prml + (prm2-prm3 ) * sum_out; 
t === t + step_size; 
EndExecutionLoop; 

The model code is written using vector notation, e.g., the gainl_out = sine_out 
. * gainl_parameter is an element-wise operation. The use of a vectored language is 
not required, however. Other "non- vectored" languages, such as C, could also be used. For 
example, if the code for the gainl block 56 output method were to be written in a non- 
vectored language such as C, the code would look like 
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int i; 

for (i=0; i< 100; i++) { 

gainl_out[i] = sine_out[i] gainl_parameter [i] ; 



where the gainl block parameter 'gainl jparameter' is assumed to have been declared as a 
vectorof 100 elements initialized to the values 1,2,3,4, 5, 100. In vector notation, 
1:100 declares an array of length 100 with values 1, 2, 3, 4, 5, 100. 

The library 24 is a repository of classes that correspond to the blocks. When a 
graphical class is used in a model, it is said to be instantiated, i.e., an instance of the 
graphical class is created for use in the model. Such an instance is a Unk to the graphical 
class that resides in the library. Block parameters are class members that are specified when 
a user constructs a new instance of a class. Instances associated with the class have 
parameter specification interfaces that allow users to define the block parameters. On a GUI, 
such parameter specification interfaces take the form of a dialog box with various parameter 
fields. Thus, the user supplies the block parameters to the block method for the appropriate 
block through a dialog box associated with the block. Alternatively, the user can specify 
parameter values programmatically using a command (e.g., the Simulink ® 'set _param' 
command). Each block in the block diagram model 52 can have between 0 and N parameters 
that are specified by a user for use in the block methods for those blocks. 

As noted earlier, the user-specified parameters are expressions that may be in the 
form of numerical values (e.g., "10"). variables defined as constants (e.g., "a" where a-10), 
interfaced variables (e.g., "a" ) or some combination thereof (e.g., a*b*sin(c)). The following 
examples are valid input for the gain parameter of the gain block, such as gain blocks 56 and 
60, as shown in FIG. 3. 



Gain: 1 . 5 



Gain: [1 2 3; 4 5 6] 



Gain: a*b+c 



Gain: [1:100] 



A scalar gain value. 

A gain value defined as an expression of the 

variables: a, b, and c. 

A 2x3 matrix of gain values. 

A vector of gain values 1, 2, 3, .. 100. 
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Gain: a ^ [ 1 : 1 0 0 ] A variable a multiplied by a vector of gain 

values 1, 2, 3, 100. 

As shown in FIG. 3, the gainl block 56 is implemented to use a block parameter 
defined as an expression 'a*b+c' (where a and b are constants, i.e., non-interfaced, and c is 
an interfaced variable therefore capable of being changed during model execution), whereas 
the gain2 block 60 is implemented to use a block parameter defined as a vector of gain values 
1, 2,3, 100. 

In addition to the user-specified parameters (e.g., dialog parameters), the user also 
supplies to the module 20 a list of all interfaced variables used by the block methods. The 
list provided by the user designates a variable, for example, variable c in the gainl block 56, 
as interfaced and provides various attributes (data type, dimensionality, complexity, storage 
class, and so forth) for each variable designated as an interfaced variable. 

FIG. 4 is an exemplary block parameter dialog box 70 for the gain2 block 60 (of FIG. 
3). The dialog box 70 includes a first parameters field 72 for specifying a parameter value, in 
the example, a gain value or range of gain values. The dialog box 70 also includes a second 
parameters field 74 for specifying the type of gain multiplication, that is, element- wise or 
matrix-wise, to be performed by the gain2 block 60. 

The module 20, and more particularly, the block diagram processing engine 26, 
generates and supports the use of run-time parameters. Run-time parameters are the block 
parameters that are used during execution of the block diagram model or in generated code. 
They are derived fi'om user-specified parameters. The run-time parameters can be the same 
as the user-specified parameters, but in many cases will be different. Whether there is a one- 
to-one correspondence between the dialog parameters and the run-time parameters will 
depend on whether a block equation parameter expression "p" can be simplified for 
optimization, as will be discussed more fully below. 

FIG. 5 depicts a flow diagram of the operational flow of the module 20 and its 
internal components. Optionally, processing of the module 20 begins by enabling a user to 
create custom blocks (e.g., the S-fimction block 64 of FIG. 3) with run-time parameters (step 
80). If the user is using only the pre-packaged blocks provided by the module's library 24, or 
if all desired custom block definition is complete, the module 20, and more particularly, the 
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model editor 22, enables the user to construct a block diagram model using the blocks (pre- 
packaged, custom or combination of the two) (step 82). Once the model has been built (and, 
preferably, saved in memory), the module 20 invokes the block diagram processing engine 
26 (step 84). The block diagram processing engine 26 takes as inputs the graphical 
description of the model (that is, the blocks and lines) and processes those inputs by either 
executing the model or, alternatively, generating code that implements the model equations 
defined by the blocks of the block diagram model. Consequently, the module retums as 
output the results of the processing by the block diagram processing engine 86, more 
specifically, either simulation results if the model is executed (indicated in dotted lines by the 
reference numeral 88a), or the automatically generated code (indicated in dotted lines by the 
reference numeral 88b). The generated code can be deployed to a target application. 

Referring to FIG. 6, the operational flow of the block diagram processing engine 26 is 
shown. The engine 26 receives the user's block diagram model as an input (step 90) and 
compiles the block diagram of the block diagram model (step 92). The compiler phase 92 
determines the appropriate order of the blocks and transforms the graphical block diagram 
into a set of executable instructions (or operations). During this transformation, any invalid 
modeling specifications (such as an invalid parameter expression) are reported as errors and 
the compilation stops. A portion of the compiler phase 92 of the block diagram processing 
engine processing relates to processing of parameters 94 for parameter optimization and 
parameter expression mapping, as will be described. The engine 26 also includes a linker 
that, given the order of the equations as determined by the compiler phase 92, links and 
allocates appropriate working areas in memory to the equations (instructions) to enable 
execution of the model (run a simulation) or code generation code (step 96). The engine 26 
executes the model to produce simulation results (or, alternatively, generates executable 
code) (step 98). 

Referring to FIG. 7, the operation of the parameter processing portion 94 of the 
compiler phase 92 (hereinafter, parameter processor 94) is as follows. For each block in the 
block diagram, the parameter processor 94 evaluates the block's user-specified parameters 
(e.g., dialog box block parameters), if any (step 100). The evaluation determines numerical 
values of parameter expressions specified by the user (e.g., entered by the user in the dialog 
box parameter fields) and constructs a data structure to describe each parameter expression 

10 
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that contains an interfaced variable. Thus, the data structure captures the interfaced, as well 
as any non-interfaced, variables for each user-specified parameter expression. Also, for each 
block in the block diagram, the parameter processor 94 sets up and maintains run-time 
parameters for the blocks (step 1 02). That is, the parameter processor 94 makes a call to the 

5 blocks to set up run-time parameters. In response, the blocks define run-time parameters, 
map the run-time parameters to the user-specified parameters and register the nm-time 
parameters with the block diagram processing engine 26. The registration provides the 
engine 26 v^th information describing each blocks use of run-time parameters, e.g, the 
number of run-time parameters used, run-time parameter values and other attributes, as well 

10 as mapping information. 

Using the information from the evaluation and run-time parameter setup steps 100, 
102, respectively, all parameter attributes that are accessed by each block method can be 
collected and processed by the block diagram processing engine 26. More specifically, the 
parameter processor 94 pools together like run-time parameters that are non-interfaced, that 

15 is, remain constant during model execution or do not change in the generated code (step 
104). After parameter pooling, the parameter processor 94 creates a run-time parameter 
expression execution structure that allows interfaced variables in run-time parameter 
expressions to be accessed during model execution (e.g., for purposes of updating) or 
mapped to generated code (step 106). 

20 The parameter processing steps will be described in greater detail with reference to 

FIGS. 8-14, 

Referring to FIG. 8, a block data structure 110 used by the parameter processing 94 is 
shown. The block data structure 1 10 only illustrates those aspects of a block that pertain to 
parameters and parameter processing. Attached to the block data structure 1 1 0 are fiinctions 

25 1 12 and 1 14 for evaluating dialog parameters ("EvalDialogParams()") and setting up runtime 
parameters ("SetupRxmtimeParams()"), respectively. In C, these fiinctions would be realized 
as function pointers within the block data structure 110. In C++, each of these functions 
would be a class method of the block class. The block data structure 110 further includes an 
internal data array 116 ("IntemalData"). The internal data array 116 includes the following: 

30 an array of abstract syntax trees (ASTs) 1 1 8, one for each block parameter field; an array of 
numerical values ("NumericDialogParamValues[nParams]") 120, which is an array of 
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numerical objects each representing the evaluated value of the block parameter expression; 
and an array of runtime parameters 122 ("RuntimeParams[nRunTimeParams]"). The 
runtime parameters array 122 is an array of parameters which are used by the block during 
execution. Also attached to the data structure 110 are various other methods or functions 
5 (used by the parameter processing 94), including a GetRuntimeParam method 124, which is 
used by the parameter pooling 104, as will be described. 

Referring to FIG. 9, details of the block parameter evaluation process 100 (from FIG. 
7) are shown. The process 100 begins (step 130) by proceeding to the next unprocessed 
block (step 132). If there are no more blocks to be processed, the process 100 terminates 
10 (step 134). If there is at least one more block yet to be processed, the process 100 invokes 
the block EvalDialogParams() method 112 (shown in FIG. 8) (step 136). The method 1 12, 
once invoked, evaluates dialog parameters in parameter expressions to resolve those 
parameter expressions for their numeric values (step 136a). The results are stored in the 
NumericDialogParamValues[nParams] array 120 (from FIG. 8). This evaluation uses a 
15 workspace (shown as shaded block 137) where the variables as well as the expressions are 

defined. For example, if a parameter expression 'a*b+c% and the variable values are defined 
in the workspace as a=l, b=2 and c=3, the evaluation resuhs in a value of 5. The invoked 
method 112 also creates an AST for any parameter expressions containing interfaced 
variables, collapsing nodes for any portion of a parameter expression containing non- 
20 interfaced variables for more efficient storage (step 136b). The method 1 12 uses a table of 
interfaced variables (shown as shaded block 138) to determine the interfaced values. The 
table 138 shows a variable c as an interfaced variable. Thus, and referring to FIG. lOA, an 
AST 140 created for the block parameter expression 'a*b+c' , in which variable c is 
determined to be interfaced. A simpUfied version of the AST 1 10 is shown in FIG. lOB as 
25 AST 142. The AST 142 is derived from the AST 1 10 by collapsing the non-interfaced nodes 
a and b of AST 110 into a single node representing the product a*b. In this example, if a=l 
and b=2, the result of multiplying the values of the variables a and b is the value '2'. 

Referring to FIG. 11, details of the runtime parameter setup process 102 (fi-om FIG. 
7) are shown. The process 102 begins (step 150) by proceeding to the next unprocessed 
30 block (step 152), If there are no more blocks to be processing, the process 102 terminates 
(step 154). If there is at least one more block yet to be processed, the process 102 invokes 
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the SetupRuntimeParamsO method 1 14 (shown in FIG. 8) (step 156). The method 1 14 sets 
up the number of run-time parameters uses by a block (step 1 56a), The number of run-time 
parameters is a function of the number of dialog parameters and evaluated numeric values of 
the dialog parameters. The setup step 156a appropriately sizes the block's 

5 RuntimeParams[nRunTimeParams] runtime parameters data array 122 (shown in FIG. 8). 
The method 1 14, as invoked, also creates each run-time parameter and stores information 
defining the run-time parameter in the runtime parameters data array 122 (step 156b). The 
run-time parameter information includes a numerical value, a mapping back to the dialog 
parameters/parameter expression firom which it was created, and the run-time parameter's 

10 characteristics (e.g., data type, numeric type (real vs. complex), whether or not the parameter 
is transforms (as v^U be later described), and dimensions. Other characteristics may be 
stored in association with the run-time parameter as well. 

Referring now to FIG. 12, the parameter pooling process 104 (fi^om FIG. 7) begins 
(step 160) by creating an empty aggregated run-time parameter table (step 162). The 

1 5 aggregated run-time parameter table is shovm as shaded block 1 63 . The process 1 04 
proceeds to the next unprocessed block (step 164). If there are no more blocks to be 
processing, the process 104 terminates (step 166). If there is at least one more block yet to be 
processed, the process 104 invokes the method GetRuntimeParam 124 (shown in FIG. 8) 
(step 168) to examine each run-time parameter and perform parameter pooling to the extent 

20 possible. More specifically, if the process 168 determines that the run-time parameter does 
not map back to dialog parameters containing interfaced variables or if the run-time 
parameter has been explicitly marked as a constant (step 168a), the process/step 168 
performs the following steps. The process 168 computes a checksum of the numeric run- 
time parameter data and, using a hash function, determines if this value exists in the 

25 aggregated run-time parameter table (step 1 68b). If the run-time parameter does not exist in 
the aggregated run-time parameter table, it is added to the table (step 168c). If it already 
exists in the table, the process 168 frees the block's numeric run-time parameter data and 
updates the table entry indicating that this run-time parameter is pooled (step 168d). It sets 
the block's numeric run-time parameter data to be equal to the table entry (168e). In an 

30 altemative implementation, the aggregated run-time parameter table could be created as the 
dialog parameters were being processed. 
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Referring to FIG. 11, details of the execution structxire setup process 106 (from FIG. 
7) are shown. The process 106 begins (step 170) by proceeding to the next unprocessed 
block (step 172). If there are no more blocks to be processing, the process 1 06 terminates 
(step 174). If there is at least one more block yet to be processed, the process 106 examines 

5 the block to determine if the block has a run-time parameter that maps back to a dialog 

parameter containing an interfaced variable and, if the block is a block that has such a run- 
time parameter, marks the block as such (step 176). During code generation, the structure of 
any block so marked is maintained by using the AST from the dialog parameter evaluation. 
During simulation, when the interfaced variable is changed, the corresponding numeric value 

1 0 of the run-time parameter is updated by re-evaluating the AST. 

The parameter processing steps 100, 102, 104, 106 will be further described in the 
paragraphs to follow. 

As discussed above, each of the blocks in the block diagram model is responsible for 
defining a mapping of run-time parameters (to be used by the block methods during model 

15 execution) to user-specified parameters. This mapping is registered with the block diagram 
processing engine 26 during the setup run-time parameters phase 102 of the parameter 
processing 94. The block diagram processing engine 26 works in conjunction with the 
blocks to manage the run-time parameters on behalf of the blocks. This management activity 
includes determining where to store the data for the run-time parameters and managing 

20 changes to parameters that occur during model execution (for example, to ensure block 

parameter integrity). The run-time parameter configuration methodology of the parameter 
processor 94 therefore enables blocks to rewrite their equations to achieve optimal 
realization. This rewriting can be done either statically, a priori to knowing parameter data 
values or dynamically after parameters data values become known or change. 

25 While a parameter is considered interfaced if the user has defined the parameter in 

terms of interfaced variables, a block can override that definition. That is, the block can 
expUcitly specify that a parameter that includes a variable declared by the user to be 
interfaced is non-interfaced by specifying that the corresponding run-time parameter is a 
constant. This type of run-time parameter can be referred to as an explicit constant run-time 

30 parameter. 

The manner in which the blocks define run-time parameters and map run-time 
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parameters to dialog parameters will now be described. The blocks define a mapping 
fimction or method that maps from run-time parameters to the dialog parameters. For 
example, the output method, y ^ OutputMethod(t,x,u,p), for the S-function block 60 (of FIG. 
3) having three parameters (prml, prm2, and prm3) is defined to be: 

5 

y =^ prml + (prm2-prm3)*u 
This output method or equation can be rewritten intemally by the block as 

10 y = rtprml + (rtprm2)*u 

where run-time parameters, 'rtprml ' and 'rtprm2\ are defined as 'prml ' 
and 'prm2-prm3\ respectively. 

The mapping function or method is called whenever the user changes the block 

15 parameters during model execution. The mapping of run-time parameters to dialog 
parameters can be any arbitrary function. 

The block registers its run-time parameter definitions with the block diagram 
processing engine 26. Fore example, the block may register that a parameter maps one-to-one 
with a dialog parameter (e.g., rtprml = prml). Alternatively, the registration could indicate a 

20 one-to-one mapping, but that the parameter is transformed, i.e., stored in a different data 

format. That is, a block can mark that its run-time parameter is transformed and tunable (i.e., 
interfaced). This block-level parameter specification allows the user to enter parameter 
information in a method that contains high-level abstractions, e.g., representing a real-world 
value by the using of a floating-point data type, as the block can convert it to a more efficient 

25 data store representation, e.g. an integer data type. The nodes of the AST that are specified as 
interfaced will be accessible in the generated code and will be represented by the efficient 
data storage representation. A transformed interfaced variable therefore has one 
representation in the block parameter specification and another representation in the 
generated code. 

30 An exemplary data structure for defining run-time parameters in the Simulink® 

context is as follows. 



15 



Docket No.: 04899-060001 



#ifndef _SS_PARAM_REC 
# define _SS__PARAM_REC 
/* 

* Typedef for the enumeration that keeps track of the "transformed" 

* status of run-time parameters. 
*/ 

typedef enum { 
/* 

* The run- time parameter is not transformed if nDialogParamlndices is 

* one and there was no alteration of the dialog parameter 

V 

RTPARAM_NOT_TRANS FORMED = 0, 
/* 

* The run- time parameter is transformed if nDialogParamlndices > 1 or 

* there was an alteration of the dialog parameter value or data type. 
*/ 

RTPARAM_TRANSFORMED = 1, 
/* 

* The run- time parameter can be marked as 'make transformed tunable' 

* if nDialogParamlndices is one and you altered the dialog parameter 

* value or data type. If the parameter field contains a single 

* tunable variable, say 'k', then the transformed data type, etc, 

* version of k will be used in the generated code. All references to 

* tunable parameters that have been transformed must be done so in 

* the same fashion, otherwise an error will be generated. 
*/ 

RTPARAM_MAKE_TRANSFORMED_TUNABLE = 2 
} TransformedFlag; 

typedef struct ssParamRec_tag { 
/* 

* The parameter characteristics 
*/ 

const char *name; /* Name of the parameter. This must point 

* to persistent memory. Do not set to a local 

* variable {static char name [32] or strings 

* "name" are okay) 
*/ 

int_T nDimensions; /* Number of dimensions for this parameter */ 

int_T *dimensions; /* Array giving the dimension (sizes) of 

* the paramter */ 

16 
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DTypeld dataTypeld; /* For built-in data types, see BuiltlnDTypeld 

* in simstruc_types . h */ 
boolean_T cotnplexSignal ; /* FALSE or TRUE */ 

/* 

* The data pointer. This is the data values for the run- time parameter. 

* Simulink needs this when creating the model. rtw file. Complex Simulink 

* signals are store interleaved. Likewise complex run -time parameters 

* must be stored interleaved. 
+ 

* Note that mxArrays store the real and complex parts of complex 

* matrices as two separate contiguous pieces of data instead of 

* interleaving the real and complex parts . */ 

void *data; 
/* 

* The data attributes pointer is a persistent storage location where the 

* user can store additional information describing the data and then 

* recover this information later (potentially in a different fxmction) . 
*/ 

const void *dataAttributes ; 
/* 

* Run- time parameters to dialog parameter map. 
* 

* For proper interaction with 'tunable parameter variables' that 

* are set via the "Tunable Parameters Dialog", Simulink requires 

* information about how the run- time parameters are derived. 
* 

* It is an implicit assumption that all run-time parameters are derived 

* from the dialog parameters, i.e., ssGetSFcnParam (S, i) . Thus each 

* run- time parameter is derived from a subset of the dialog parameters: 

* run-time_parameter = some_f unction {subset of dialog parameters) . 

* In the simplest case, 

* run-time_parameter = a specific dialog parameter 
* 

* The following information specifies which dialog parameters are 

* used in deriving a specific run- time parameter. For the simplest case, 

* we have 

* nDialogParamlndices - 1,- 

* dialogParamlndices = k; 

* transformed = false ; 

* This case is important to identify because this will allow for 

* efficient and correct code generation of run- time parameters when they 

17 
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* map directly back to tunable parameter variables specified in 

* the 'Tunable Parameters Dialog' . 
V 

int_T nDlgParamlndices ; 

int_T *dlgParamIndices; 



Trans forme dFlag transformed; 
boolean_T output AsMatrix; 

} ssParamRec ; 
#endif 

The mapping information (ssParamRec->nDlgParamIndices , 
ssParamRec->nlgParamIndices) is used in setting up the expression mapping of the 
interfaced variables. In creating the run-time parameter, an initial value is specified 
(ssParamRec->data). The initial value is used in parameter pooling step. 

As mentioned above, parameter pooling only applies to the constant run-time 
parameters. A run-time parameter is designated as constant if either of the following 
conditions hold: i) the run-time parameter does not map back to a dialog parameter that 
contains an interfaced variable; or ii) the run-time parameter is explicitly declared as constant 
by the block (as discussed earlier). 

Generally, the parameter pooling step 104 identifies block parameters having 
parameter data that matches a given criterion, and allocates only one copy of the parameter 
data for all references to a given parameter data set. The criterion can require that the data 
match bit-for-bit. Parameter pooling that uses such an "exact data match" matching criterion 
is referred to herein as "uniform parameter pooling". Alternatively, the criterion can require 
that the data match exactly (i.e., bit-for-bit) only after a mapping fimction has been applied to 
the data. This latter type of parameter pooling is referred to herein as "non-uniform 
parameter pooling." Consequently, v^hen non-uniform parameter pooling is employed, a 
block reconstructs the parameter data it needs for execution jfrom the pooled parameters by 
using the mapping function dviring execution. 

The uniform parameter pooling requires an identical data matching. If the values of 
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/* Array of length nDialogParamlndices 

* indicating the dialog parameters that 

* are used in deriving the run- time 

* parameter */ 
/* Transformed status */ 

/* Write out parameter as a vector (false) 

* [default] or a matrix (true) 
*/ 
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the constant run-time parameters are bit-for-bit the same, then the block diagram processing 
engine 26 creates one memory location for the run-time parameter references. This memory 
location is referred to as a pooled parameter. The uniform parameter pooling looks for all 
registered run-time parameters with the same value and other attributes (i.e., data type, 
dimension, and so forth) and combines them into one run-time parameter in one location. 

Non-uniform parameter pooling occurs when a one-to-one function is used to match 
data. The block is responsible for registering the data-matching function with the block 
diagram processing engine 26 during run-time parameter setup. The block diagram 
processing engine 26 may also have a set of predefined data-matching functions. The block 
diagram processing engine 26 is responsible for invoking these data-matching functions on 
the run-time parameters to see if the run-time parameters are identical. For example, suppose 
that a first block A is using a first constant run-time parameter i : lOO, a vector of length 100 
with values 1 , 2, . . . , 1 00, and a second block B is using a second constant run-time parameter 
2:2: 100, a vector of length 50 with values 2, 4, . . ., 100. A data matching function takes the 
two constant run-time parameters as input arguments and retums true (success) if it finds a 
mapping between the two parameters. One of the arguments, say a first argument 
(my_r t_prin), is the run-time parameter of block B and the other argument, say a second 
argument (rt_prm), is a potential constant run-time parameter, such as the run-time 
parameter of block A, with which the block B may be pooled. 

Suppose that block B defines the data matching function to be as follows: 

Pmap (my_rt_prm, rtprm) 

If (DataEleinentTypesMatch(my_rt_prm, rtprm) ) and 

AnIndexExistsThatMapsBetweenPrms (my_rt_prm, rtprm) ) then 
Return true; 
Else 

Return falser- 
End Pmap; 

The function DataEiementTypesMatch ensures that the function is examining 
constant run-time parameters of the same data type (e.g., both IEEE double precision 
floating-point numbers). The function, AnindexExistsThatMapsBetweenPrms looks for an 

19 
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indexing operator that can recover my_rt_prm from the rt prm. For this example, the 
indexing operator is the value 2, because block B's constant run-time parameter equals block 
A's constant run-time parameter at every other point. 

If the block diagram processing engine 22 generates code from the model, the 
generated code conforms to the definitions of interfaced variables supplied by the user and all 
constant run-time parameters are pooled together. 

Referring back to the parameter processing step 106 (of FIG. 7), the execution 
Structure allows parameter expressions with explicitly interfaced variables to be mapped to 
generated code. As mentioned before, a parameter can be an expression of numeric values, 
variables, and fimctions. Furthermore, some of parameter expression variables can be 
designated as interfaced variables, either in accordance with the user specification or as 
specified explicitly by the block when run-time parameters are defined. The purpose of 
interfaced variables is to provide the execution firamework with a way to access and modify 
interfaced variables used by any number of blocks in the block diagram. The execution 
structure allows for a one-to-one mapping of variables in a parameter expression to support 
different host/target representations. The expression mapping methodology can be extended 
to cover transformed interfaced variables as well. Therefore, the expression mapping 
provides a means by which user marked variables within parameter expressions can be 
accessed and modified during simulation or within the automatically generated code for the 
block diagram. 

The techniques of parameter optimization, pooling and expression mapping are 
fiuther illustrated for the bdexample (model 52 of FIG. 3) in code produced by The 
Simulink/Real-Time Workshop (which corresponds to the block diagram processing engine 
26), as shown in the Appendix. 

The exact mechanism by which the blocks map their equations to generated code is 
not central to the concept of parameter processing as described herein. The Simulink 4 and 
the Real-Time Workshop 4 products by The MathWorks Inc. use a text processing utility to 
transform the block source code to the required output. Of course, other implementations are 
possible. For example, the blocks could have methods that produce the output equations in 
ASCII form that is suitable for placement in the generated code. 

The parameter processing techniques as thus described enable users to solve a wide 

20 
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range of problems. Users benefit from the parameter pooling and expression mapping by 
using pre-packaged blocks provided with the Simulink® tool or blocks available from third 
parties. Users also are able to extend the tool by defining their own blocks to work 
seamlessly with the block diagram tool to achieve the benefits of parameter pooling and 
expression mapping. 

During code generation, the blocks provide information about how the generated code 
should look. In the case of the S-fimction block example, a file defming the format of the 
block output is as follows: 

% implements "sfun_runtime_opt" "C" 

%% Function: mdlOutputs ^===:====~=^==================^===============^=======^=== 

%% Abstract: 

%% 

%% y = rtprml + rtprm2 * u 

%% 

%function Outputs (block, system) Output 
/* %<Type> Block: %<Name> */ 
{ 

%assign rollVars = ["U", "P"] 

%roll sigldx = RollRegions, lev = 5, block, "Roller", rollVars 
%assign u = LibBlocklnputSignal (0, "", lev, sigldx) 

%assign y = LibBlockOutputSignal (0, lev, sigldx) 

%assign rtprml = LibBlockParameter (rtprml, lev, sigldx) 

%assign rtprm2 = LibBlockParameter (rtprm2, lev, sigldx) 

%<y> = %<rtprml> * %<rtprm2> * %<u>; ^ How to format the output equation 
%endroll 

} 

%endfunction 

It is to be iinderstood that while the invention has been described in conjunction with 
the detailed description thereof, the foregoing description is intended to illustrate and not 
limit the scope of the invention, which is defined by the scope of the appended claims. Other 
embodiments are within the scope of the following claims. 
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APPENDIX 

Executable code produced by The Simulink/Real-Time Workshop for the example 

"bdexamplel" is as follows: 

/* 

5 * bdexamplel.c 

* Real-Time Workshop code generation for Simulink model "bdexamplel .mdl" . 
* 

* Model Version : 1.23 

10 * Real-Time Workshop file version : 4.0 $Date: 2000/09/19 19:45:27 $ 

* Real-Time Workshop file generated on : Sun Jul 01 23:51:00 2001 

* TLC version : 4.0 (Aug 21 2000) 

* C source code generated on : Sun Jul 01 23:51:00 2001 
* 

15 * Relevant TLC Options: 

* InlineParameters = 1 

* RollThreshold - 5 

* CodeFormat = RealTime 

20 * Simulink model settings: 



25 



Solver 
StartTime 
StopTime 
FixedStep 



FixedStep 
0.0 s 
10.0 3 
0.2 s 



#include <math.h> 
#include <string.h> 
#include "bdexamplel . h" 
30 #include "bdexamplel_prm.h" 

/* Start of Functions in model "bdexamplel" */ 

/* Start the model */ 
35 void MdlStart (void) 

{ 

/*" (no start code required) */ 

} 

40 /* Compute block outputs */ 

void MdlOutputs (int__T tid) 
{ 

/* local block i/o variables */ 
real_T rtb_temp0 [ 100 ] ; 
45 real_T rtb_templ [100] ; 
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/* Sin Block: <Root>/Sine Wave */ 
{ 

int_T il; 

real_T *yO = &rtb_tempO [0] ; 

const real_T *p_Amplitude = &rtP.pl[0]; ^ example of a pooled parameter 

const real_T *p_Frequency = &rtP.pl[03; <r example of a pooled parameter 

for {il-0; il < 100; il++) { 

yO[il] - (p_Amplitude[il] ) * sin ( (p_Frequency [il] ) * ssGetT(rtS) + (0.0)); 

} 

} 

/* Gain Block: <Root>/Gainl */ 
{ 

int_T il; 

const real_T *uO = &rtb_tempO [0] ; 
real_T *yO = &rtb_templ [0] ; 

for (il=0; il < 100; il++) { 

yO[il] = uO[il] * (1.0 * 2.0+c); example of expression mapping: c is 

preserved 

} 

} 

/* Gain Block: <Root>/Gain2 
{ 

int_T il; 

const real_T *uO = &rtb_templ [0] ; 
real_T *yO = &rtb_templ [ 0] ; 

const real_T *p_Gain = &rtP.pl[0]; <- example of a pooled parameter 

for (il==0; il < 100; il++) { 

yO[il] = u0[il] * (p_Gain[il] ) ; 

} 

} 

/* Lookup Block: <Root>/Look-Up Table 
{ 

int_T il; 

const real_T *u0 = &rtb__tempO [0] ; 
real^T *y0 = Strtb__tempO [0] ; 

for (il-0; il < 100; il++) { 

yO[il] = rt_Lookup (&rtP.Look_Up_Table_XData[03 , 
100, 
u0[il] , 

23 
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&rtP.pl[0]); <r example of a pooled parameter 

} 

} 

/* Sum Block: <Root>/Sum */ 
{ 

int_T il; 

const real_T *uO = &rtb_templ [0] ; 
const real_T *ul = &rtb_teiapO [0] ; 
real_T *yO ^ &rtt»_templ [0] ; 

for (il-0; il < 100; il++) { 
yO[il] = uO[il] + ul[il] ; 

} 

} 

/* S-Function Block: <Root>/S-Functionl */ 
{ 

{ 

int_T il; 

const real_T *uO = &rtb_teinpl [0] ; 
real_T *yO = &rtb_teinpl [0] ; 

const real_T *p__rtprm2 = &rtP . S_Functionl_rtpnn2 [0 ] ; example of parameter 

op t imi z a t i on 

for (il=0; il < 100; il++) { 

yO[il] = (5.0) * (p_rtprm2 [il] ) * uO[il]; 

} 

} 

} 

/* Outport Block: <Root>/Outl 
{ 

int_T il; 

real_T *yO - srtY .Outl [0] ; 

const real__T *uO = &rtb_teinpl [0] ; 

for (il-O; il < 100; il++) { 
yO[il] = uO[il]; 

} 

} 

} 

/* Perform model update */ 
void MdlUpdate (int_T tid) 
{ 
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/* (no update code required) */ 

} 

/* Terminate function */ 
void MdlTerminate (void) 
{ 

/* (no terminate code required) 

} 

/* End of Functions in model "bdexamplel" */ 
#include "bdexamplel_reg. h" 
/* [EOF] bdexamplel. c */ 



In a generated header file, the block diagram parameters data structure is defined to 

typedef struct Parameters_tag { 

real_T pi [100}; /* Expression: a* (1:100) 

* External Mode Tunable: no 

* Referenced by blocks: 

* <Root>/Sine Wave 

* <Root>/Sine Wave 

* <Root>/Gain2 

* <Root>/Look-Up Table 
*/ 

real_T Look_Up_Table_XData [100] ; /* Expression: -1:2.01/100:1 

* External Mode Tunable: no 

* Referenced by block: 

* <Root>/Look-Up Table 

real_T S_Functionl_rtprm2 [100] ; /* Computed Parameter: rtprm2 

* External Mode Tunable: no 

* Referenced by block: 

* <Root>/S-Functionl 

} Parameters; 



In this example, the S-fiinction block implements the output equation, 

output = prral * (prm2-prm3) ■^input_signal 

and the implementation uses run-time parameters where the first run-time parameter 
(rtprml) equals prml and the second run-time parameter (rtprm2) equals prm2-prm3, 
giving: 

25 
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output = rtprml ^ (rtprm2 ) ^input_signal 

source code for this S-function is as follows: 

/* $Revision: 1.1 $ */ 





File : s f un_runt irae_opt . c 




* 


Abstract : 




* 


Illustration of run-time parameter optimization where the 




* 


block dialog is assumed to have the following parameters: 




* 


prml: a scalar or a vector of length N 




* 


prm2: a scalar or a vector of length N 




* 
* 


prm3: a scalar or a vector of length N 




* 


t-hf:a nni-nnt' pmi^Rtinrt i defined as : 




* 


y = prml + {prm2-prm3 ) *u 






where u is the input and y is the output. To optimize the 


execution 


* 


and reduce memory, this equation can be written as : 




* 


y = rtprml + (rtprm2)*u 




+ 


where the run-time parameters are defined to be: 






rtprml = prml 




* 
* 


rtprm2 = prm2-prm3 




* 


In this example, these parameters are 'fixed' during model exection 


* 


This means there is no need for the mdlProcessParameters 


function. 


* 


/ 





tdefine S_FUNCTION_NAME sf un_runtime_opt 
#define S_FUNCTION__LEVEL 2 

#include <string.h> 
#include "tmwtypes.h" 
#include "simstruc.h" 

tdefine PRM1_IDX 0 

#define PRM1{S) ssGetSFcnParam (S, PRH1_IDX) 
#define PRM2_IDX 1 

tdefine PRM2(S) ssGetSFcnParam(S, PRM2__IDX) 
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#define PRM3_IDX 2 

#define PRM3(S) ssGetSFcnParam(S, PRM3_IDX) 
#define NPARAMS 3 

/* Function: mdllnitializeSizes ==^========:=====================^================= 

* Abstract: 

* Call mdlCheckParameters to verify that the parameters are okay, 

* then setup sizes of the various vectors. 
*/ 

static void mdllnitializeSizes (SiiuStruct *S) 
{ 

int vectLen; 

ssSetNumSFcnPararos (S, NPARAMS); <r Block requires three dialog parameters 
#if defined {MATLAB_MEX_FILE) 

if (ssGetNumSFcnParams (S) ! = ssGetSFcnParamsCount (S) ) { 

return; /* Parameter mismatch will be reported by Simulink */ 

} 

#endif 

ssSetSFcnParamTunable(S, PRM1_IDX, false) ; 
ssSetSFcnParamTunable (S, PRM2_IDX, false) ; 
ssSetSFcnParamTunable(S, PRM3_IDX, false) ; 

ssSetNumContStates (S, 0); 
ssSetNumDiscStates (S, 0); 

/* 

* Determine the maximum parameter vector length. 

* This will be the input/output width. Note the 

* input can be scalar expanded: 

* u > block > y 

* length (u) === 1 or vectLen 

* length (y) vectLen. 
*/ 

{ 

int_T i ; 
vectLen - 1; 

for {i = 0; i < NPARAMS; i++) { 

const itixArray *mx = ssGetSFcnParam(S, i) ; 

int nEls = mxGetNumberOf Elements (mx) ; 

if (nEls > 1) { 

vectLen - nEls; 
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break; 

} 

} 

} 

if (! ssSetNiimlnput Ports {S, 1)) return; 
ssSetlnputPortWidth (S, 0, vectLen} ; 
ssSetlnputPortDirectFeedThrough (S, 0, 1); 
ssSetInputPortOverWritable{S, 0, 1) ; 
ssSetlnputPortReusableiS, 0, 1); 
ssSetlnputPortRequiredContiguous (S, 0, 1) ; 

if { ! ssSetNumOutputPorts (S, 1)) return; 
ssSetOutputPortWidth(S, 0, vectLen); 
ssSetOutputPortReusable {S, 0, 1); 

ssSetNumSampleTimes (S, 1) ; 
ssSetNumRWork(S, 0) ; 
3SSetNumIWork(S, 0); 
ssSetNumPWork(S, 0); 
ssSetNumModes {S, 0); 
ssSetNumNonsampledZCs (S, 0) ; 

/* Take care when specifying exception free code - see sfuntmpl.doc */ 

ssSetOptions (S, (SS_OPTION_EXCEPTION__FREE_CODE i 

SS_OPTION_ALLOW_INPUT_SCALAR_EXPANSION I 
SS_OPTIOK_USE_TLC_WITH_ACCELERATOR I 
SS_OPTION_CALL_TERiy[INATE_ON_EXIT | 
SS_OPTION_ALLOW_INPUT_SCALAR_EXPANSION) ) ; 

} /* end mdllnitializeSizes */ 

/* Function: mdllnitializeSampleTimes =========^============================ 

* Abstract: 

* Specif iy that we inherit our sample time from the driving block. 
*/ 

static void mdllnitializeSampleTimes (SimStruct *S) 
{ 

ssSetSampleTime{S, 0, INHERITED_SAMPLE_TIME) ; 
ssSetOffsetTime CS, 0, 0.0); 

} 

# define MDL_SET_WORK_WIDTHS /* Change to #undef to remove function */ 

#if defined {MDL_SET_WORK_WIDTHS) && def ined {MATLAB_MEX_FILE) 

/* Function: mdlSetWorkWidths ============================================== 

* Abstract: 

* Set up run-time parameters. 
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static void mdlSetWorkWidths { SimStruct ^S) 
{ 

if { i ssSetNumRunTimeParams (S, 2)} return; <- register during run-time set-up phase 
that two parameters are needed 

{ 

ssParamRec rtprml; 

int_T dlgParamlndex - PRM1_IDX; 

int T dim = mxGetNumberOf Element s {PRMl (S) ) ; 



rtprml . 


, name 




"rtprml" ; 


rtprml . 


, nDimensions 




1; 


rtprml . 


.dimensions 




Sdim; 


rtprml . 


.dataTypeld 




SS_DOUBLE; 


rtprml , 


. complexSignal 




COMPLEX_NO; 


rtprml , 


.data 




(void *)mxGetPr (PRMl (S) ) ; 


rtprml , 


. dataAttributes 




NULL; 


rtprml . 


. nDlgParamlndices 




1; 


rtprml 


. dlgParamlndices 




& dl gPa r ami ndex ; 


rtprml 


.transformed 




false; 


rtprml 


. outputAsMatrix 




false; 



if { IssSetRunTimeParamlnfo (S, 0, &rtprml) ) return; <r register the first run- 
time parameter as equal to the first dialog parameter (prml) . 



ssParamRec 


rtprmZ; 




real_T 


*prm2 = 


mxGetPr (PRM2 (S) } ; 


int_T 


nEls2 = 


mxGetNumberOf Elements (ssGetSFcnParam(S, PRM2_IDX) ) ; 


int_T 


inc2 = 


(nEls2 > 1) ; 


real_T 


*prm3 = 


mxGetPr (PRM3 (S) ) ; 


int_T 


nEls3 = 


mxGetKumberOfElements (ssGetSFcnParam(S, PRM3_IDX) ) ; 


int_T 


inc3 = 


{nEls3 > 1) ; 


int__T 


nEls = 


nEls2 > nEl33? nEls2: nElsS; 


real_T 


*buf = 


malloc{nEls*sizeof {buf [0] ) ) ; 


int_T 


dlgParamlndices [2] ; 


int_T 


i; 





if (buf == NULL) { 

ssSetErrorStatus{S, "memory alloc error in sfun_runtime_opt") ; 
return; 

} 
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for (i = 0; i < nEls; { 
buf[i] = *prm2 - *prm3; 
prm2 += inc2; 
prm3 += inc3; 



dlgParamlndices [0] ~ 2; 
dlgParamlndices [1] = 3; 



rtprm2 . name 
rtprm2 . nDimensions 
rtprm2 . dimensions 
rtprm2 . dataTypeld 
rtprm2 . complexSignal 
rtprm2 , data 
]:tprm2 . dataAttributes 
rtprm2 . nDlgParamlndices 
rtprm2 . dlgParamlndices 
rtprm2 . transformed 
rtprm2 . outputAsMatrix 



"rtprm2 " ; 
1; 

&nEls; 
SS_DOUBLE; 
COMPLEX_NO; 
(void *)buf; 
NULL ; 
2; 

dlgParamlndices ; 

true; 

false; 



if (!ssSetRunTimeParamInfo(S, 1, &rtprm2) ) { <r register the second dialog 
return; paramerer equal to the dialog 

J parameters: prm2-prm3. 

} 
} 

#endif /* MDL SET_WORK_WIDTHS */ 



/* Function: mdlOutputs ======================^ 

* Abstract: 

* y = rtprml + {rtprm2)*u 
* 

static void mdlOutputs (SimStruct int_T tid) 

{ 



int_T 






el; 








int_T 






uWidth 




ssGetInputPortWidth(S,0) ; 




int_T 






uinc 




(uWidth > 1) ; 




const 


real_ 


_T 


*u 




ssGetlnputPortRealSignal (S, 0) ; 




int_T 






yWidth 




ssGetOutputPortWidth{S,0) ; 




real_T 




*y 




ssGetOutputPortRealSignal (S, 0) ; 




const 


real_ 


_T 


* rtprml 




(const real_T *) ssGetRunTimeParamlnfo (S, 0) 


->data; 


int_T 






incl 




ssGetRunTimeParamInf o ( S , 0 ) ->dimensions [ 0 ] 


> 1; 


const 


real_ 


_T 


*rtprm2 




(const real T *) ssGetRunTimeParamInf o (S, 1) 


->data; 


int T 






inc2 




SsGetRunTimeParamInf o (S, 1) ->dimensions [ 0] 


> 1; 



/* 
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* Generate sum and if needed average, 
for (el = 0; el < yWidth; el++) { 

*y++ = *rtprml + (*rtprin2) * {*u); <r Use run-time parameters in output method 

u += ulnc; 
rtprral += incl; 
rtprm2 += inc2; 

} 

} /* end radl Outputs */ 

/* Function: mdlTerminate ==-===================================-=======-====== 

* Abstract: 

* Free the 2nd run-tirtie parameter data because it was allocated by 

* this block (i.e., not a direct map to dialog parameters). 
*/ 

static void mdlTerminate {SimStruct *S) 
{ 

if (ssGetNumRunTimeParams (S) >= 2 && 

ssGetRunTimeParamInf o (S, 1) != NULL && 
ssGetRunTimeParamlnfo (S, 1) ->data != NULL) { 
free (ssGetRunTimeParamlnfo (S, 1) ->data) ; 

} 

} 

#ifdef MATLAB_MEX_FILE /* Is this file being compiled as a MEX-file? */ 

#include "simulink.c" /* MEX-file interface mechanism */ 

#else 

tinclude "cg_sfun.h" /* Code generation registration function */ 

#endif 
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